Public hotspot access points have recently become extremely popular. One of the key requirements in using access points is seamlessness, i.e., the hotspot should accommodate the communication settings on user machines as much as possible without user intervention in changing such settings. One particular problem to the user of hotspots requires that a hotspot accommodate whatever browser settings a user may have on a machine. For example, a business traveler's browser is likely to have a proxy server configuration. When the business traveler is using a hotspot, the proxy server name cannot be resolved because the domain name is not recognized in a registry and the browser shows a failure page preventing the traveler from accessing the Internet or a remote computer.
A further problematic scenario occurs when a user takes his office laptop to a public hotspot and starts browsing the web. The browser on the laptop is configured with a proxy server name that is not resolvable outside of the user's company intranet. Because of the proxy configuration, for any web page the user tries to access, the browser sends a web page request in a special format to the proxy server. But since the proxy server name cannot be resolved into an Internet Protocol (IP) address, the browser would immediately show a failure page to the user. Further, since the hotspot could not even receive the very first browser request, the hotspot could not provide any assistance to the user. The key here is to help the user's machine resolve this proxy server name so that the browser could at least start interacting with the hotspot and the hotspot can seamlessly translate and bridge the requests sent from the user's machine. The problem, however, is that the local Domain Name System (DNS) server in the hotspot does not know what proxy name is configured in the user browser and is, thus, unable to specially treat the DNS query for the proxy name from the user's machine.
One solution to the above problem is to let the local DNS server blindly return local IP addresses for any host names that the local DNS server could not resolve as this, of course, will include the proxy server name on a user machine's browser. The problem with this approach is that the user is confused by the results of such of operation by receiving a web page that was not requested by the user. For example, even if a user types in a wrong server name, which normally should not be resolved, the local DNS server still returns a valid IP address. More importantly, because the hotspot does not know which IP address corresponds to user's proxy server, it is impossible to transparently process the user's browser requests. Thus, the problem of resolving a request for a web page, as described above, still remains.